In recent years, drawing attention as reasonable data services for corporate use is wide area Ethernet VPN (Virtual Private Network) service (wide area Ether) which is an expansion of Ethernet techniques widely used in LAN (Local Area Network) to a wide area network (WAN). Although WAN requires an Operations, Administration and Maintenance (OAM) function, Ethernet techniques used in LAN originally fail to have an OAM function, which is a problem to be solved. Under these circumstances, some of standardization groups in recent years proceed with standardization related to OAM functions in the Ethernet techniques.
One of representative OAM functions is the Trace-route function widely used as one of OAM functions in the Internet. The Trace-route function is used for obtaining information about devices located before reaching a certain target device.
As a method of obtaining information of devices located before reaching a target device in the related art, one example of which is recited in Japanese Patent Laying-Open No. 2004-147223 (Patent Literature 1), description will be made of the Trace-route function (hereinafter, referred to as Link Trace (LT) after naming of ITU-T Y.17ethoam) in ITU-T Y.17ethoam for which standardization of the Ethernet OAM techniques is in progress with reference to FIG. 33. FIG. 33 shows a case where a terminal T2 executes LT for checking information about devices located before reaching a terminal T1. A network shown in FIG. 33 is an existing layer 2 (L2) network for executing MAC (Media Access Control) address learning based frame transfer on topology by STP (Spanning Tree Protocol)/RSTP (Rapid Spanning Tree Protocol) (a link between existing switches LS6 and LS7 is a blocking link). Letter t1 or t2 indicated at a port of existing switches LS1 through LS8 shows MAC address learning condition. In a standard method of ITU-T Y.17ethoam, a Request frame with a TTL (Time to Live) value stored is transmitted to a target device and a Reply frame with the TTL value subtracted by 1 is returned to a transmission source by a relay node and the target device, so that the transmission source executes rearrangement based on the TTL values of the Reply frames to obtain information about devices located before reaching the target device.
Description will be specifically made of execution of LT by the terminal T2 for checking information about devices located before reaching the terminal T1. The terminal T2 as a transmission source transmits an LT Request frame (here, an initial value of TTL is set to be 255). The existing switch LS5 which is a relay node having received the frame transfers a request frame with the TTL value subtracted by 1 (TTL=254) to a port having learned MAC#t1, a MAC address of the terminal T1 as a target device, as well as returning an LT Reply frame with the TTL value stored to the Request issuing source device. Similarly to the existing switch LS5, the existing switch LS4 as a relay node at a stage subsequent to the existing switch LS5 transfers a Request frame with the TTL value subtracted by 1 (TTL=253) to a port having learned MAC#t1, the MAC address of the terminal T1 as a target device, as well as returning an LT Reply frame with the TTL value stored to the Request issuing source device. Relay node existing switches LS3, LS2 and LS1 to follow execute the same operation. Thereafter, when the LT Request frame arrives at the terminal T1 as a target device, the terminal T1, upon reception of the LT Request frame directed to its own device, abandons the LT Request frame to return an LT Reply frame (TTL=249) with the TTL value subtracted by 1 stored to the Request issuing source device. Upon receiving the LT Reply frames from the existing switches LS1 through LS5 as relay nodes and the terminal T1 as a target, the terminal T2 as the Request issuing source device rearranges Relay frame transmission sources based on the stored TTL values to obtain LS5->LS4->LS3->LS2->LS1->T1 as the information about devices located before reaching the target device.
Patent Literature 1: Japanese Patent Laying-Open No. 2004-147223
As described in the foregoing, however, while in the existing LT, a transfer route in a normal state can be confirmed, a failing part at the time of a failure can not be specified.
The problem to be solved will be described with reference to FIG. 34. Also shown in FIG. 34, similarly to FIG. 33, is LT from the terminal T2 (MAC#t2) to the terminal T1 (MAC#t1). Illustrated in FIG. 34(1) is a normal transfer state, in which a link between the existing switches LS6 and LS7 is a blocking link. In addition, each node learns the MAC#t1 and the MAC#t2 by frame transfer between the terminal T1 and the terminal T2. When executing LT from the terminal T2 to the terminal T1 here, a result of the LT is obtained along the route having learned the MAC#t1, a route LS5->LS4->LS3->LS2->LS1->T1 as has described with reference to FIG. 33. When there occurs here a failure on a link between the existing switches LS2 and LS3 as shown in FIG. 34(2), STP/RSTP is restructured to make the link between the existing switches LS6 and LS7 be an active link. Thereafter, as shown in FIG. 34(3), a learned MAC address entry (an entry indicated by ◯ in the figure) at a port having received a topology change message in the course of restructuring of STP/RSTP is flushed. Thereafter, when frame transfer between the MAC#t1 and the MAC#t2 is resumed, in each node, each port on a route as of after switching relearns each MAC address (an entry indicated by □ in the figure) as shown in FIG. 34(4). As a result, execution of LT from the terminal T2 to the terminal T1 obtains a route LS5->LS6->LS7->LS8->LS1->T1 based on a new learning result related to the terminal T1 (MAC#t1). The route obtained here is a transfer route as of after route switching and is not a transfer route attaining an object of specifying a failing part on a route as of before switching. For specifying a failing part, it is demanded to have a Reply returned from nodes preceding to the failing part on the route as of before switching. In an ordinary layer 2 network, however, when a route is switched to a new transfer route after failure occurrence, a MAC address entry as of before the switching is flushed to execute LT according to a MAC address entry learned on the new transfer route as of after switching, so that it is impossible to execute LT on the route as of before switching to specify a failing part.
An object of the present invention is to provide a frame transfer route confirmation method, a node, a program thereof and a frame transfer route confirmation system which enables a route as of after route switching to be specified when a failure occurs, as well as enabling a route to a node immediately preceding to a failure occurrence part on a route as of before the route switching node to be specified, thereby specifying a failing part.